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Prufungsantrag gem. § 44 PatG ist gestellt 

@ Infrastruktur fur ein System von verteilten Objektmanager-Komponenten 

® Bei der Oberwachung einer Kraftwerksanlage sind eine 
Vtelzahl von Oberwachungseinrichtungen mit Datenverar- 
beitungskomponenten vorgesehen, die gemaS der dtesen 
Komponenten zugeteilten technischen Aufgaben an ver- 
schiedenen Stellert im Kraftwerk und entkoppolt voneinan- 
der installiart sind. Insbesondere bei redundant eusgefuhr- 
ten Komponenten stattt sich das Problem bei einem System 
mit einer Vielzahl von Komponenten, welchan Redundanz- 
Zustand die jeweils redundant ausgefuhrten Komponenten 
besitzen. Die erfindungsgemaBe Losung dieses Problems 
siaht es vor, daG elne Infrastruktur fur ain System von 
verteilten Objektmanager-Komponenten mit einer Anzahl 
von rechnergestutzten Objektmanager-Komponenten, die 
jeweils mindestens einen Objektmanager ausfuhren, vorge- 
™ sehen ist. wobei fur redundant ausgefuhrte Objektmanager- 
f Komponenten oder Objektmanager der Zustend 'prozefifuh- 
rend" und entsprechend "nicht-prozeSfuhrend* uberwacht 
und fur alle u brig on Objektmanager-Komponenten zugeng* 
lich ist. Auf diese Wei so bewirkt die Infrastruktur eine 
Transparsnz bezuglich des Redundanz-Zustandes von re- 
dundant ausgefuhrten K mponenten im System fur alia 
ubrigen am System beteiligte Komponenten oder Objektma- 
nager. Eine ubergeordnete Oberwachun gains tanz ist auf 
diese Weise entbehrlich. 

Die Erfindung ist prinzipiail bei alien Einrichtungen zur 
Steuerung und Oberwachung k mplexer technischer Anla- 
gen einsetxbar. Sie ist insbes ndere fur das Leitsystem von 
Kraftwerkcantsgen vorgasehen. 




CM 

m 

LU 

Q 



Die folgenden Angaben sind d n v m Anmelder Inger iehten Untarl-gcn sr. tr.c. 

BUNDESDRUCKEREI 10.85 502 050/176 



11/27 




DE 195 



Beschreibung 

Die Erfindung bezieht sich auf eine Infrastruktur fur 
ein System von verteilten Objektmanager-Komponen- 
ten, insbesondere filr ein Leitsystem einer Kraftwerks- 
anlage, mil einer Anzahl von rechnergestutzien Objekt- 
manager- Komponenten. 

In einer Kraftwerksanlage sollen Oberwachungsein- 
richtungen die aktuellen Betriebszustande der Anlage 
erkennbar machen und Abweichungen von einem SoII- 
zustand melden. Dazu ist eine umfangreiche MeBwert- 
erfassung der Betriebszustande aller Anlagenteile, eine 
umfangreiche und der Komplexitat der Anlage gerecht- 
werdende MeBwertbewertung und eine unier hoher In- 
formationsverdichtung visualisiert aufbereitete Status- 
anzeige fiir die Betriebszustande der Anlagenteile erfor- 
derlich. 

Diese vorstehend genannten Aufgaben soil ein Leit- 
system erfullen. Bedingt durch die hohe Komplexitat 
solcher technischen Anlagen muQ ein solches Leitsy- 
stem einfach und geradlinig strukturiert sein. Dies be- 
deutet zum einen, daB Anlagenteile mittels des Leitsy- 
stems uberwachbar und einstellbar sind und zum ande- 
ren, da8 neue und/oder iiberarbeitete und geanderte 
Kontroll-, Einstell- und/oder Auswerteoptionen in ein- 
facher Weise in das bestehende Leitsystem und seine 
Architektur integrierbar sind. 

In der deutschen Patentanmeldung P 44 16 547.1 ist 
ein Leitsystem, insbesondere ein rechnergesttitztes Leit- 
system, vorgeschlagen, bei dem eine hohe Konfigurier- 
barkeit einer die MeBwerte be- und auswertenden Ebe- 
ne innerhalb des Leitsystems gegeben ist Dies wird im 
einzelnen dadurch erreicht, daB die Leitebene modular 
aufgebaut ist und mehrere Funktionsbausteine umfaBt, 
die entsprechend ihrer jeweiligen Funktion Eingangs- 
werte verarbeiten und unter Benicksichtigung einer 
Anzahl von zu losenden technischen Anwendungen un- 
tereinander verknlipfbar sind. Aufgrund dieses modula- 
ren Aufbaus der Leitebene und ihrer Systeme sind eine 
nahezu beliebige Strukturierbarkeit und graphische 
Konfigurierbarkeit des Leitsystems in dieser Ebene ge- 
geben. Es konnen jederzeit Funktionsbausteine modifi- 
ziert, erganzt, weggenommen oder neu verknupft wer- 
den, urn eine zu losende technische Anwendung, wie 
z. B. die ProzeBfuhrung bestimmter Anlagenteile, die 
ProzeBinformation, die KenngroBenberechnung oder 
die Bilanzierung, durchfiihren zu konnen. Die dabei ver- 
arbeiteten Eingangswerte konnen die unmittelbar von 
der Automatisierungsebene erhaltenen MeBwerte, be- 
reits mit einer Zugehorigkeitsfunktion bewertete MeB- 
werte, Zwischenresultate anderer Funktionsbausteine 
und uber die Betriebsfiihrungsebene vorgebbare pro- 
jektierbare Parameter sein. 

Bei einem solchen meist rechnergestutzien Leitsy- 
stem ist es wimschenswert, wenn die Leitebene und die 
mit der Leitebene verbundenen Ebenen innerhalb einer 
gemeinsamen Systemumgebung, einer sogenannten In- 
frastruktur, gefiihrt sind. Hierzu ist es bekannt, ein Be- 
triebssystem, vorzugsweise ein handelsiibliches Be- 
triebssystem, wie z. B. UNIX oder OS 2, zu verwenden, 
das die Betriebsfiihrungsebene, die Leitebene und die 
Automatisierungsebene sowie einen Datentransfer zwi- 
schen diesen Ebenen unterhalt. Bei solchen Betriebssy- 
stemen ist es dariiber hinaus wiinschenswert, wenn die 
freie Verknupfbarkeit der in der Leitebene angeordne- 
ten Funktionsbausteine unterstutzt wird, und wenn eine 
weitgehende Unabhangigkeit des Leitsystems von der 
Innovationsgcschwindigkeit der Rechncr- Hardware er- 
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reicht wird. 

Derzeit handelstibiiche Betriebssysteme, wie z. B. 
UNIX oder OS 2, sind jedoch uberfordert, wenn es im 
Rahmen einer Infrastruktur fiir ein System von verteil- 
5 ten Objektmanager-Komponenten darum geht, bei- 
spielsweise ein aus einer Anzahl von rechnergestutzien 
Objektmanager-Komponenten bestehendes verteiltes 
System hochzufahren. Eine nicht zufriedenstellende 
derzeitige Losung sieht hierzu einen ubergeordneten 

io Rechner vor, der zu Beginn des Anlaufs die Informatio- 
nen iiber die gesamte {Configuration aller existierenden 
Objektmanager-Komponenten kennt Bedingt durch 
die Komplexitat einer Kraftwerksanlage kommt es zu 
Storungen, wenn beispielsweise der iibergeordnete 

15 Rechner gestort ist, oder wenn die Datenverbindungen 
zu diesem ubergeordneten Rechner gestort sind, oder 
wenn sich an der Gesamtkonfiguration noch kurzfristig 
vor dem Anlaufen etwas geandert hat und diese Ande- 
rungen noch nicht zu Beginn des Anlaufs beriicksichtigt 

20 worden sind. 

Weitere Probleme treten auf, wenn einzelne Objekt- 
manager-Komponenten redundant ausgefuhrt sind. Die 
Probleme werden durch die Tatsache verursacht, daB 
der iibergeordnete Rechner zu jeder Zeit Kenntnis da- 

25 von haben muB, welche Objektmanager-Komponente 
prozeBfuhrend und welche Objektmanager-Kompo- 
nente nicht-prozeBfuhrend isl 

Der Erfindung liegt daher die Aufgabe zugrunde eine 
Infrastruktur fiir ein System von verteilten Objektma- 

30 nager-Komponenten anzugeben, mit der jederzeit si- 
chergestellt ist, daB eine storungsfrei vorliegende Infor- 
mation uber den Zustand von redundant ausgefiihrten 
Objektmanager-Komponenten vorliegt. 

Diese Aufgabe wird erfindungsgemaB dadurch gelost, 

35 daB eine Infrastruktur fiir ein System von verteilten 
Objektmanager-Komponenten mit einer Anzahl von 
rechnergestiitzten Objektmanager-Komponenten, die 
jeweils mindestens einen Objektmanager ausfuhren, 
vorgesehen ist, wobei fur redundant ausgefuhrte Ob- 

40 jektmanager-Komponenten oder Objektmanager der 
Zustand "prozeBfuhrend" und entsprechend "nicht-pro- 
zeBfuhrend" uberwachbar und fur alle ubrigen Objekt- 
manager-Komponenten zuganglich ist. 

Hierbei wird unter einer Objektmanager-Komponen- 

45 te beispielsweise eine Workstation, ein Personal-Com- 
puter, Automatisierungssysterne, wie z. B. die Siemens- 
Siematic S5 und S7, oder vergleichbare rechnergestiitz- 
te Einrichtungen verstanden. Unter einem Objektmana- 
ger werden insbesondere bei einer Kraftwerksanlage 

50 die folgenden Komponenten verstanden. Es sind dies 
das Man-Machine- Interface, das Archiv, die Protokolli- 
ste, die Verarbeitungseinrichtung fiir die Bausteintech- 
nik, eine Datenbank fiir Beschreibungs-, Symptom- und 
Diagnosetexte und ein sogenannter AS-Reprasentant, 

55 der das Automatisierungssystem, also die Schnittstelle 
zwischen KraftwerksprozeB und Datenverarbeitung, 
stutzt. 

Auf diese Weise ist es moglich, daB jede Objektmana- 
ger-Komponente in Folge der entsprechenden Ausge- 

eo staltung der Infrastruktur Kenntnis uber den aktuellen 
Redundanz-Zustand der am System beteiligten Objekt- 
manager-Komponenten und Objektmanager hat Feh- 
ler, die durch eine iibergeordnete Oberwachungsinstanz 
auftreten konnen. sind auf diese Weise eliminiert. 

65 In vorteilhafter Weise kann ein Zustandsubergang ei- 
ner Objektmanager-Komponente oder eines Objekt- 
managers bei Vorliegen eines Ausfallereignisses selbst- 
tatig erfolgen. Dies bedeutet insbesondere, daB die In- 
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frastruktur cine fur alle Objektrnanager-Komponenien 
zugangliche Meldung in auf ebensolche Meldungen 
wartende Schnittstellen der Objektmanager-Kompo- 
nenten schreibt. 

In weiter zweckmaBiger Weise ist die Infrastruktur 5 
derart ertuchtigt, daQ die Obermittlung eines datenie- 
senden Aufirages an den prozeBftihrenden Server er- 
folgt, und/oder das die Obermittlung eines datenschrei- 
benden Auftrages an alle zueinander redundanten Ob- 
jektmanager-Komponenten oder Objektmanager er- 10 
folgt Auf diese Weise ist es gewahrleistet, daB ein da- 
tenlesender Client unverzuglich bedient wird bzw. daB 
eine redundant ausgefuhrte, abe: derzeit nicht-prozeB- 
fuhrende Objektmanager-Komponente oder Objekt- 
manager jederzeit in der Lage ist, an die prozeBftthren- -.5 
de Stelle zu treten. 

Eine weitere vorteilhafte Ausgcstaltung der Erfin- 
dung sieht es vor, daB zum Aufdaten von Objektmana- 
gern auf wiederanlaufenden redundanzen Objektmana- 
ger-Komponenten der fuhrende Server auf Auftrag ein 20 
konsistentes Abbild seiner ProzeBdaten erstellt und 
zum aufrufenden Client ubertragt. Auf diese Weise ent- 
halt der auf der wiederanlaufenden redundanten Ob- 
jektmanager-Komponente installierte Objektmanager 
nach definicrter Aufforderung zu einem definienen 25 
Zeitpunkt alle fur den Betrieb des Objektmanagers er- 
forderliche Daten. Es entstehen also keine Datenlucken 
oder Fehler durch die Obermittlung nicht aktueller Pro- 
zeBdaten. 

In besonders einfacher Weise laBt sich die Erfindung 30 
ausgestalten, wenn eine Objektmanager-Komponente 
oder ein Objektmanager in dem jeweiligen Server- 
Haupttetl eine Schnittstelle aufweist, die eine Anderung 
des Redundanz-Zustandes der entsprechenden Kompo- 
nente oder des entsprechenden Objektmanagers erfaBu 35 

Ausfiihrungsbeispiele der Erfindung werden anhand 
einerZeichnung naher erlautert. Dabei zeigen: 

Fig. 1 in schematischer Darstellung eine Infrastruktur 
fur ein verteiltes System von Objektmanager-Kompo- 
nenten; 4 o 

Fig. 2 in schematischer Darstellung einen in die Infra- 
struktur eingebetteten Objektmanager; 

Fig. 3 in schematischer Darstellung den Oberwa- 
chungsmechanismus der gemaB Fig. 1 dargestellten In- 
frastruktur; 45 

Fig. 4 in schematischer Darstellung den Oberwa- 
chungsmechanismus gemaB Fig. 3 bei dem Ausfall einer 
Objektmanager-Komponente; und 

Fig. 5 in scherriatischer Darstellung den Oberwa- 
chungsmechanismus in der Infrastruktur gemaB den 
Fig. 3 und 4 in zwei Oberwachungsebenen. 

In den Fig. i bis 5 haben gleiche Teile die gleichen 
Bezugszeichen. 

In der in Fig. 1 gezeigten schematischen Darstellung 
erkennt man die Infrastruktur 2 fur ein verteiltes System 
18 von Objektmanager-Komponenten 4 bis 16 als 
schraffien unterlegte Flache. Das System 18 ist als Leit- 
system fiir eine Kraftwerksanlage vorgesehea Die Ob- 
jektmanager-Komponenten 4 bis 16 konnen Datenver- 
arbeitungsaniagen beliebiger Art, wie z. B. GroBrech- 
ner, Workstations, Personal-Computer und Host- Reen- 
ter jeglicher Art, sein. Auf den einzelnen Objektmana- 
ger-Komponenten 4 bis I6 f von denen die Komponen- 
ten 10a und 10b sowie 12a und 12b redundant ausge- 
fuhrt sind. werden Objektmanager ausgefuhrt. 

Unter Objekten werden Daten jeglicher Art, wie z. B. 
binare Signale. hexadezimale Signale. wie z. B. ReaJ- 
Werte, Integer- Werte, Boolean-Werte oder String-Ke:- 
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ten, verstanden. Objektmanager sind also solche hard- 
waremaBig oder auch softwaremaBig realisierte Einhei- 
ten. die Objekte beiiebiger Art verwaken. Objektmana- 
ger sind beispielsweise das Man-Machine-Interface 
(MMI) 20, das Archiv 22 zur Aufzeichnung der Ge- 
schichte des Kraftwerks (redundant ausgefuhrt als 22a 
und 22b), der Protokollverwalter 24 (ebenfalls redun- 
dant ausgefuhrt als 24a und 24b), der Verwalter 26 fur 
die Datenverarbeitung der in Bausteintechnik vorgese- 
henen unc hier nicht weiter dargestellten Leitebene, die 
Datenbank 28 fur Beschreibungsdaten und der Repra- 
sentant 30 des Automatisierungssystems. Wie beispiels- 
weise anhand des Reprasentanten 30 des Automatisie- 
rungssystems gezeigt, kann ein Objektmanager auch auf 
mehreren Objektmanager-Komponenten, hier die 
Komponenten 4 bis 8 und 16, gleichzeitig ausgefuhn 
wercen. 

Beim Anlauf des Systems 18 werden von einer dezen- 
tral angeordneten Initialisierungsdatei 32 die Anlaufda- 
ten in die Infrastruktur 2 eingegeben. Jeder der Objekt- 
manager-Komponenten 4 bis 16 hat einen Teil seiner 
zur Verfiigung stehenden Rechenleistung reserviert, um 
die Infrastruktur 2 in hardwaremaBig verschalteter 
Form oder auch in softwaremaBig installierter Form zu 
betreiben. Die Aniaufdaten der Initialisierungsdatei 32 
enthalten einen dezentraien Algorithmus, nach dem in 
einer ersten Phase des Anlaufs die Objektmanager- 
Komponenten 4 bis 16 untereinander Kontakt aufneh- 
men und der Infrastruktur 2 und damit alien an der 
Infrastruktur 2 beteiligten Komponenten 4 bis 16 ihre 
lokal installierten Objektmanager 20 bis 30 bekannt. 
Nach dieser Kontaktaufnahme sind auf jeder Objekt- 
manager-Komponente 4 bis 16 alle anlaufenden Objekt- 
manager-Komponenten und alle dort existierenden Ob- 
jektmanager bekannt. 

In einer zweiten Phase werden mittels der Infrastruk- 
tur 2 auf den Objektmanager-Komponenten 4 bis 16 die 
lokal installierten Objektmanager 20 bis 30 gestartet 
Die Infrastruktur 2 wartet ferner darauf, daB die Ob- 
jektmanager 20 bis 30 ihre Verfugbarkeit als Server 
bekannt geben, und aktualisiert — auch wenn der Ober- 
wachungsmechanismus einen Abbruch eines Objektma- 
nagers erkannt hat — den neuen Zustand zusammen rnit 
einer detaillierten Adressinformation auf alien Objekt- 
manager-Komponenten 4 bis 16. In einer dritten Phase 
werden die Objektmanager 20 und 26 auf den redundant 
vorliegendcn Objektmanager-Komponenten 10a, 10b 
bzw. 12a, 12b gestartet. Dabei datet sich der jeweils 
fuhrende Redundanzpartner am alien Objektmanager- 
50 Komponenten 4 bis 16 gemeinsamen AnlaufprozeB auf 
und der oder die nicht fuhrenden Objektmanagerdaten 
sich beim jeweils fuhrenden Objektmanager auf. 

Die Infrastruktur 2 unterstutzt auch eine weitere An- 
laufsitua;ion. bei der sich eine abgebrochene Objektma- 
55 nager-Komponenie, beispielsweise die Komponente 6, 
in ein etabliertes Teilsystem. bestehend aus den Kompo- 
nenten 4. 8 bis 16. wieder eingliedert. Die sich einglie- 
dernde Objektmanager-Komponente 6 stellt sich zu- 
nachst bei einer schon irn Teilsystem etablierten Objekt- 
co manager-Kompor.ente, beispielsweise der Komponente 
8. vor. ir.dem die Objektmanager-Komponente 6 ihre 
lokal installierten Objektmanager, hier der Reprasen- 
;ant 30 des Automatisierungssystems, mitteilt. Die loka- 
le Infrastruktur der Objektmanager-Komponente 8. 
65 dar2es;e:h durch die schraffierte Flache innerhalb des 
Symbols fur die Objektmanager-Komponente 8, macht 
c:c s en emgliedernde Objektmanager-Komponente 6 
rn •.•:jcli:r:er. Teiisystem bekannt. Die sich eingliedern- 
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de Objektmanager-Komponente 6 erhalt von der Kom- 
ponente 8, bei der sie sich vorgestellt hat, die Informa- 
tionen tiber die Zustande und Adressen der Objektma- 
nager-Komponente 4, 8 bis 16 des etablierten Teilsy- 
stems und der darauf installierten Objektmanager. Auf 
diese Weise wird die Objektmanager* Komponente 6 in 
das etablierte Teiisystem eingegliedert ohne daB eine 
iibergeordnete Instanz. beispielsweise ein Leitrechner, 
vorgesehen ist, der die Konfiguration, Zustande und 
Adressen der ubrigen Objektmanager-Komponenten 
kennt. Diese Informationen sind vielmehr auf jeder Ob- 
jektmanager-Komponente 4 bis 16 im lokalen Teil der 
Infrastruktur 2 enthalten, so daB auch jede Anderung 
d s Status einer Objektmanager- Komponente oder ei- 
nes Objektmanagers alien Objektmanager-Komponen- 
ten unmittelbar zuganglich ist Dies wirkt sich besonders 
vorteilhaft auf die Serverfunktionen der Objektmana- 
ger und auf die Kenntnis deren Verfugbarkeit im ge- 
samten System 18 aus. In beiden Anlaufsituationen star- 
tet die Infrastruktur 2 die iokal installierten Objektma- 
nager, in dem sie deren Initiaiisierungsprozesse erzeugt. 
Objektmanager, die dem System 18 keine Serverlei- 
stung zur Verfugung stellen, sind mit diesem Schritt 
sofort verfugbar. 

Der Abbruch eines Objektmanagers 20 bis 30 wah- 
rend des Anlaufs wirkt sich abhangig vom Vorhanden- 
sein einer Redundanz auf den Zustand der entsprechen- 
den Objektmanager-Komponente 4 bis 16 aus: Bei vor- 
handener Redundanz werden die schon aktiven Objekt- 
manager beendet und die Objektmanager-Komponente 
wird ais "abgebrochen" fur alle ubrigen Objektmanager- 
Komponenten zuganglich markiert. Ohne vorhandene 
Redundanz wird der Anlauf der Objektmanager-Kom- 
ponente fortgesetzt. Nur der vom Abbruch betroffene 
Objektmanager wird als "abgebrochen" markiert. 

In Fig. 2 ist in schematischer Darstellung gezeigt, in 
welcher Weise ein Objektmanager, hier beispielsweise 
der Objektmanager 30, aufgebaut und in die Infrastruk- 
tur 2 eingebunden ist Im vorliegenden Fall weist der 
Objektmanager 30 zwei Client-Schnittstellen 32, 34, ei- 
nen Init-Server 36, einen Server-Hauptteil 38, einen Ser- 
ver-Obertragungsteil 40 und einen Server 42 fiir Projek- 
tierungsdienste auf. 

Ober die Client-Schnittstellen 32, 34, die auch als 
Schnittstelle Client-Infrastruktur 2 bezeichnet werden 
kann, werden Auftrage iiber die Infrastruktur 2 an Ser- 
ver ausgegeben, und es kdnnen Antworten vom Server 
Uber die Infrastruktur 2 in der Schnittstelle empfangen 
werden. Hierbei kann die Schnittstelle als Mehrfach- 
wartestelle ausgefuhrt sein, so daB es moglich ist, auf die 
Ergebnisse verschiedener Auftrage unabhangig vonein- 
ander warten zu konnen, was sich besonders vorteilhaft 
auf die Synchronisation von Datenaustauschvorgangen 
auswirkt. 

Der Init-Server 36 wird beim Anlauf des Objektma- 
nagers 30 aufgerufen. Dieser Init-Server 36 startet und 
uberwacht alle weiteren Prozesse, die auf dem Objekt- 
manager 30 ausgefuhrt werden. Der Init-Server 36 teilt 
alien ubrigen Prozessen daruber hinaus wichtige Konfi- 
gurations- und Adressinformationen mit. Falls der Ob- 
jektmanager 30 beendet werden soli, wird dies dem Init- 
Server 36 von der Infrastruktur 2 iiber ein entsprechen- 
des Signal, beispielsweise ein UNIX-Signal, mitgeteilt. 
Das Beenden des Objektmanagers 30 wird der Infra- 
struktur 2 durch das Be nden des Init-Servers 36 mitge- 
teilt. 

Der Server-Hauptteil 38 stellt dem Server fur alle 
"Nutzfunktionen" des Objektmanagers 30 dar. Im Ser- 



ver-Hauptteil 38 ruft das Hauptprogramm nach der ei- 
eenen Initialisierung durch den Init-Server 36 eine 
Uberwachungsfunktion auf. Diese Oberwachungsfunk- 
tion wartet uber die gesamte Lebensdauer des Server- 
5 Hauptteils 38 auf Client-Auftrage und ruft entsprechend 
dieser Auftrage Server- Funktionen auf, d. h. der Server- 
Hauptteil 38 wartet in einer Wartestelle in der Infra- 
struktur 2 auf entsprechende Client-Auftrage. Diese 
Funktion ist daher eine Art vorgeschobener Horchpo- 

io sten aus dem Objektmanager 30 heraus in die Infra- 
struktur 2. Erst wenn der Server-Hauptteil 38 beendet 
wird, verlaBt diese Funktion die Infrastruktur 2 und 
kehrt in das Hauptprogramm zuruck. 

Der Server-Obertragungsteil 40 stellt einen in den 

is ProzeB des Objektmanagers 30 eingebundenen Funk- 
tionssatz dar, iiber den Server antworten (z. B. fiir konti- 
nuierliche Auftrage) abgegeben werden. Der Server- 
Obertragungsteil 40 ubertragt, falls sich ein Client iiber 
den Server-Hauptteil 38 angemeldet hat, die gewtinsch- 

20 ten Ereignisse oder sonstige Ereignisse von kontinuierli- 
chen Auftragen. 

Der Server 42 fiir Projektierungsdienste wartet nach 
seiner Aktivierung auf Projektierungsauftrage und legt 
die Projektierungsinformation in eine Objektmanager 

25 spezifische Datenbasis ab oder gibt sie an die innerhalb 
des Objektmanagers 30 betroffenen Prozesse weiter. 

Die Infrastruktur 2 uberwacht und steuert die ge- 
samte Kommunikation in einer Weise, daB jedes Objekt 
ein internes Kennzeichen und einen Auspragungstyp 

30 umfaBt, anhand deren der Objektmanager, beispielswei- 
se Objektmanager 30 f ermittelbar ist, der dieses Objekt 
verwaltet. Hierbei wird unter einem Objekt jede Infor- 
mation verstanden, die in einer Datenverarbeitungsan- 
lage zur Kommunikation von Prozessen ausgetauscht 

35 oder ubertragen wird. Mit dem Auspragungstyp eines 
Objektes ist beispielsweise zunachst gemeint, ob dieses 
Objekt der verfahrenstechnischen Welt, der leittechni- 
schen Welt oder der anlagentechnischen Welt zuzuord- 
nen ist. Weiter beinhaltet der Auspragungstyp eine 

40 Klassifizierung des Objekts nach seiner Aufgabenurnge- 
bung, beispielsweise kann ein Objekt Alarm- oder Tole- 
ranzmeldungen, Hardware-Geratefehlern, Busfehlern 
oder Funktionsfehlern zugeordnet sein. Das interne 
Kennzeichen ist nicht gleichbedeutend mit dem Begriff 

45 "Adresse", weil das interne Kennzeichen keinerlei Orts- 
information uber die Lage des Objektes besitzt Dar- 
uber hinaus kann dem internen Kennzeichen nicht ein- 
deutig eine Adresse zugeordnet werden, denn verschie- 
dene Daten eines Objekts konnen von verschicdenen 

so Objektmanagern 20 bis 30 verwaltet werden, die unter 
Umstanden auf verschiedenen Objektmanager-Kompo- 
nenten 4 bis 16 angesiedelt sind. Auf diese Weise ist mit 
besonders vorteilhafter Wirkung eine Adressierung von 
Objekten anhand ihrer Eigenschaften, d. h. eine assozia- 

55 tive Adressierung, moglich. Hierdurch vereinfacht sich 
die Projektierung, weil ganze Objekt-Kiassen ausge- 
wahlt werden konnen, ohne daB deren Lage im einzel- 
nen einem Objektmanager oder einer Objektmanager- 
Komponente bekannt sein mussen. So kann beispiels- 

6o weise von dem Objektmanager 4, dem Man-Machine- 
Interface, das Kommando abgesetzt werden "Suche 
Leittechnikfehler". Auf diese Weise sind in dem gesam- 
ten System 18 nur solche Objekte angesprochen, die 
gcmaB ihres internen Kennzeichens und des Auspra- 

65 gungstyps in die Signalklasse w Leittechnikfehle^* , hinein- 
fallen. 

Die Kommunikation im System 18 kann zum einen 
e ne von einem Server-gesteuerte diskontinuierliche 
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Kommunikation und zum anderen eine von einem 
Client-gesteuerte, kontinuierliche Kommunikation sein. 
Bei der Server-gesteuerten Kommunikation muB der 
Client den Umfang der Ergebnisse nicht kennen. Teiler- 
gebnisse konnen ubertragen werden, wenn sie anfatien. 
Durch die Ciient-gesteuerte Kommunikation wird das 
gesamte Kommunikationsaufkommen im System 18 
verringert, weil keine Auftragswiederhoiungen notwen- 
dig sind. Die Infrastruktur 2 ist hierbei derart konzipiert, 
daB bei dem Vorlicgen eines Kommunikationsauftrages 
eines CHenten alle an diesem Auftrag beteiligten Server 
unmittelbar und nur einmalig zur Datenausgabe aufge- 
fordert sind Gleichzeitig kann mit einer solchen Auffor- 
derung eine Synchronisationsaufforderung an alle betei- 
ligten Server ergehen. Weiter kann in besonders zweck- 
maBiger Weise die Meldung des Vollzugs der Synchro- 
nisation an den Client erst dann ergehen. wenn die Be- 
reitschaft zur Datenausgabe aller verfiigbaren Server 
vorliegt, so daB auch hier das Kommunikationsaufkom- 
men besonders gering ist, weil keine Nachfragen des 
Clients nach bestimmten Ergebnissen an einzelne Ser- 
ver ergehen. 

Eine weitere vorteilhafte Ausgestaltung der Infra- 
struktur 2 siehi es vor. daB eine Wiederanmeldung eines 
noch anstehenden Auftrages eines CHenten bei einem 
wiederverfiigbar gewordcncn Server vorgesehen ist. 
Die Infrastruktur 2 stellt also Ressourcen bereit, die alle 
im System 18 eingegangenen Auftrage erfafit unci spei- 
chert, falls ein Server zur Auftragserledigung nicht ver- 
fugbar ist. Da die Infrastruktur gleichzeitig jede Zu- 
standsanderung eines Servers bezuglich seiner Verftig- 
barkeit erfaBt, wird eine Auftragserledigung unmittel- 
bar nach Wiederverfugbarkeit eines Servers "ange- 
mahnt". 

Die Infrastruktur 2 ist weiter in der Lage einen Kom- 
munikationsauftrag bezuglich der Parameterversor- 
gung zu prufen und den Auftrag bei fehlerhafter Para- 
meterversorgung unter Angabe eines Fehiercodes ab- 
zulehnen. Auf diese Weise konnen beispielsweise Fehler 
vermieden werden, wenn bei der Suche nach einem 
Leittechnikfehler in der verfahrenstechnischen oder an- 
lagemechnischen Welt gesucht wird. Ein solcher Fehler 
ist nur in der ieittechnischen Welt zu finden, d. h. also bei 
den Datenquellen und Senken,die vom Auspragungstyp 
her mit der Fehlerklasse ubereinstimmen. 

Hierbei kann das dynamische Verhaken der Erledi- 
gung eines Kommunikationsauftrages nachvollziehbar 
und verifizierbar sein. Eine solche Funktton kann bei- 
spielsweise uber den Protokollverwaiter 24 an die dem 
Man-Machine-Interface zugeordneten Drucker ausge- 
geben werden. Dies ist in der Projektierungsphase be- 
sonders bedeutsarn, wenn man nachvollziehen will, wel- 
che Daten woher geiaden wurden. und in welcher Weise 
daraus Ergebnisse berechne: wurden. und wohin die 
Ergebnisse gesendet wurden. 

In Fig. 3 ist der Oberwachungsmechanismus der Ob- 
jektmanager-Komponenten 4 bis 16 in dem System 18 
dargesteilt. Der Mechanismus wird anhand der Objekt- 
manager-Komponenten 4 bis 8 erlauter;. Die Objekt- 
manager-Komponente 6 arbeitet bei der Oberwachung 
als Client fur die Objektmanager-Komponente 8 und als 
Server fur die Objektmanager-Komponente 4. Die Ob- 
jektrnanager-Komponenten 4 bis 16 sind zur Oberwa- 
chung ihres Zustandes in einem iogischen Ring angeord- 
net, so daB keine iibergeordnete Cberwachungskompo- 
nente erforderlich ist. Die Oberwachung erfolgt nach 
dem Client-Server Prinzip. Die ais Client arbeitende 
Objektmanager-Komponente 6 sendet in derinierten 
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Zeitabstanden ein Signal (Objekt) an die cntsprechend 
als Server ausgebildete Objektmanager-Komponente 8. 
Diese Komponente 8 sendet daraufhin ein "Lebenszei- 
chen" an die Komponente 6. En gleicher Weise erhalt die 
5 Komponente 6 von der Komponente 4 in definiercen 
Zeitabstanden eine Aufforderung. ein "Lebenszeichen" 
zu senden. Zur Serversuche lauft auf alien Objektmana- 
ger-Komponenten 4 bis 16 der gieiche Algorithmus ab t 
beispielsweise konnen die Objektmanager-Komponen- 

io ten 4 bis 16 ihren Oberwacher und den zu Gberwachen- 
den anhand der aiphabetischen Reihenfolge ihrer Be- 
nennung ermitteln. 

In Fig. 4 ist eine gegenuber Fig. 3 geringfugig modifi- 
zierte Konfiguration ces Systems 18 dargesteilt. Hier 

is sind die Objektrnanager-Komponenten 6 und 10a aus- 
gefallen. Der Server der ausgefallenen Objektmanager- 
Komponente 6 kennt die Konfiguration dieser Kompo- 
nente und teilt uber die Infrastruktur 2 den verbleiben- 
den Objektrnanager-Komponenten alle mit der Objekt- 

20 manager-Komponente ausgefallenen Objektmanager 
mit. Dies ist im vorliegenden Fall der auf der Objektma- 
nager-Komponente 6 durchgefuhrte Objektmanager 
30. GemaB der vorgegebenen Algorithmus hat die Ob- 
jektmanager-Komponente 4 nun nicht die Objektmana- 

25 ger-Komponente 6 als Server, sondern die Objektmana- 
ger-Komponente 8, so daB die im verbleibenden System 
aktiven Objektrnanager-Komponenten 4, 8 bis 16 wie- 
der einen logischen Oberwachungsring bilden. Will sich 
die Objektmanager-Komponente 6 wieder in das Sy- 

30 stem eingliedern, meldet sie sich bei der Objektmana- 
ger-Komponente 8 an, gibt ihre lokal installierten Ob- 
jektmanager, hier der Objektmanager 30. bekannt und 
erfahrt von der Objektmanager-Komponente 8 die 
Konfiguration und Zustande aller ubrigen Objektmana- 

35 ger-Komponenten. Dies ist durch die gestrichelten Pfei- 
le 44 symbolisiert. 

Ein weiterer Spezialfall ist fiir die Objektrnanager- 
Komponenten 10a und 10b dargesteilt Diese Kompo- 
nente ist redundant ausgefuhrt Im gezeigten Fall ist die 

ao Komponente 10a ausgefallen. Der Server cieser Kom- 
ponente 10a kennt die Konfiguration dieser Komponen- 
te und die auf dieser Komponente lokal installierten 
Objektmanager, hier das Man-Machine-Interface 20, 
und teilt den ubrigen Objektrnanager-Komponenten, 

45 die mit der Objektmanager-Komponente ausgefallenen 
Objektmanager mit- Hierbei ist es die Infrastruktur 2, 
die ein fur alle Objektrnanager-Komponenten zugangli- 
ches Ereignis generiert, das insbesondere den verblei- 
benden Komponemen mitteilt. ob eine Objektmanager- 

50 Komponente "prozeBfiihrend" oder ''nicht- prozeBfuh- 
rend n ist bei redundanter Ausfuhrung der jeweiligen 
Komponente. 

Nach dem Ausfall der Komponente 10a erfolgt der 
ZustandsObergang der Objektmanager-Komponente 

55 von "nicht-prozeBfuhrend" nach "prozeBfuhrend" der 
Komponente 10b selbsttatig. Hierbei kann es weiter 
vorgesehen sein, daB zum Aufdaten von Objektmana- 
gern auf wiederanlaufenden redundanten Objektrnana- 
ger-Komponenten der prozeBfuhrende Server auf Auf- 

60 trag ein konsistentes Abbild seiner Proze3daten erstellt 
und zum aufrufenden Client, hier der Server der ausge- 
fallenen Objektmanager-Komponente 10a, ubenragt. 
Um den Redundanz-Zustand einer Objektmanager- 
Komponente fur die ubrigen Komponemen zuganglich 

65 zu machen, ist es vorgesehen. daB jede Objektmanager- 
Komponente 4 bis 16 oder jeder Objektmanager in dem 
entsprechenden Server-Hauptteil 38 eine Schnittstelle 
aufweist. die eine Anderung des Redundanz-Zus:andes 
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der jeweils anderen Objektmanager-Komponenten 
oder Objektmanager erfaBt. 

Insbesondere fiir die Handhabung einer sicheren Da- 
tenubertragung von redundant ausgefuhrten Objektma- 
nager-Kompon nten ist die Infrastruktur 2 derart aus- 5 
gestaltet, daQ die Obermittlung eines datenlesenden 
Auftrages selbsttatig an den prozeBfiihrenden Server 
erfolgt Hierzu dient beispielsweise der Eintrag in der 
vorstehend genannten Schnittstelle bezuglich des Zu- 
stands einer Objektmanager-Komponente oder eines 10 
Objektmanagers. Gleichzeitig sorgt die Infrastruktur 2 
dafur, daB die Obermittlung eines datenschreibenden 
Auftrages an alle zueinander redundanten Objektmana- 
ger-Komponenten oder Objektmanager erfolgt, so daB 
der nicht prozeBfuhrende Teil jederzeit in der Lage ist, 15 
die ProzeBfiihrung zu ubernehmen. 

Auch der logische Ring zur Oberwachung der Ob- 
jektmanager-Komponenten 4 bis 16 schlieBt sich bei 
dem Ausfall der Objektmanager-Komponente 10a 
selbsttatig, weil die Objektmanager-Komponenten 4 20 
und 12a, 12b automatisch auf die redundante Objektma- 
nager-Komponente 10b umschalten, die ihren Zustand 
von "nicht-prozeBfuhrend" nach "prozeBfuhrend" gean- 
dert hat, wie dies die Pfeile 46, 48 symbolisieren. 

In Fig. 5 ist nochmals der logische Ring zur Oberwa- 25 
chung der Objektmanager-Komponenten 4 bis 16 sche- 
matisch dargestellt Hierbei soil deutlich gemacht wer- 
den. daB die Oberwachung in zwei Oberwachungsebe- 
nen erfolgt In der ersten Oberwachungsebene iiberwa- 
chen sich die Objektmanager-Komponenten 4 bis 16 30 
selbsttatig im gemaB Fig. 3 beschriebenen Ring. Dies ist 
in Fig. 5 durch die Pfeilverbindungen von Objektmana- 
ger-Komponente zu Objektmanager-Komponente 
symbolisiert 

An der hier ausgewahlten Objektmanager-Kompo- 35 
nente 14 ist die zweite Oberwachungsebene schema- 
tisch dargestellt. Innerhalb einer Objektmanager-Kom- 
ponente werden zyklisch wiederkehrend die Zustande 
der einzelnen lokal instailierten Objektmanager, hier 
der redundant ausgefiihrte Protokollverwalter 24a, 24b 40 
und die Datenbank 28 fiir Beschreibungsdaten, iiber- 
wacht Auf diese Weise ist eine Entkopplung der Ober- 
wachungsprozesse fur Objektmanager-Komponenten 
und Objektmanager erreicht, so daB beispielsweise nach 
dem Ausfall eines einzelnen Objektmanagers nicht die 45 
gesamte Objektmanager-Komponente als ausgefallen 
gemeldet werden muB. 

Patentanspruche 

50 

1. Infrastruktur (2) fiir ein System von verteilten 
Objektmanager-Komponenten (4 bis 16), insbeson- 
dere fur ein Leitsystem einer Kraftwerksanlage, mit 
einer Anzahl von rechnergestiitzten Objektmana- 
ger-Komponenten, die jeweils mindestens einen 55 
Objektmanager ausfuhren, wobci fiir redundant 
ausgefiihrte Objektmanager-Komponenten (10a, 
10b. 12a. 12b) oder Objektmanager (22a. 22b. 24a, 
24b) der Zustand "prozeBfuhrend" und entspre- 
chend "nicht-prozeBfuhrend" uberwacht und fur al- 60 
le ubrigen Objektmanager-Komponenten (4, 6, 8, 
14, 16) zuganglich ist. 

2. Infrastruktur (2) nach Anspruch 1, dadurch ge- 
kennzeichnet, daB ein Zustandsubergang einer Ob- 
jektmanager-Komponente (10a, 10b, 12a. 12b) oder 65 
eines Objektmanagers (22a, 22b. 24a, 24b) bei Vor- 
liegen eines Ausfallereignisses selbsttatig erfolgt 

3. Infrastruktur (2) nach Anspruch 1 oder 2, dadurch 
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gekennzeichnet, daB die Obermittlung eines daten- 
lesenden Auftrages an den jeweils prozeBfuhren- 
den Server einer Objektmanager-Komponente 
oder eines Objektmanagers erfolgt 

4. Infrastruktur (2) nach einem der Anspruche 1 bis 

3, dadurch gekennzeichnet, daB die Obermittlung 
eines datenschreibenden Auftrages an alle zueinan- 
der redundanten Objektmanager-Komponenten 
(10a, 10b, 12a, 12b) oder Objektmanager (22a, 22b, 
24a, 24b) erfolgt 

5. Infrastruktur (2) nach einem der Anspruche 1 bis 

4, dadurch gekennzeichnet, daB zum Aufdaten von 
Objektmanagern (20, 26) auf wiederanlaufenden re- 
dundanten Objektmanager-Komponenten der fun- 
rende Server auf Auftrag ein konsistentes Abbtld 
seiner ProzeBdaten erstellt und zum aufrufenden 
Client ubertragt 

6. Infrastruktur (2) nach Anspruch 5, dadurch ge- 
kennzeichnet daB eine Objektmanager-Kompo- 
nente (10a, 10b, 12a, 12b) oder ein Objektmanager 
(22a, 22b, 24a, 24b) in einem Server-Hauptteil (38) 
eine Schnittstelle (36) aufweist die eine Anderung 
des Redundanz-Zustandes erfaBt 
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